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CHAPTER  1 


.  INTRODUCTION 

BACKGROUND 

The  Aeronautical  Systems  Division  (ASD)  of  Air  Force 
Systems  Command  (AFSC)  has  been  directed  to  establish  an 
Acquisition  Logistics  Deputate. (23)  The  purpose  of  this 
new  deputate  is  to  provide  integrated  management  of  the  15 
logistics  elements  in  the  systems  acquisition  process. 
These  elements  range  from  maintainability  to  technical 
data  and  constitute  a  major  portion  of  the  acquisition 
effort  of  a  program  office. 

To  perform  this  task  of  integrated  logistics 
management,  the  new  deputate  and  the  program  offices 
require  a  management  information  system  (MIS)  to  gather, 
store,  and  process  the  logistics  data  generated  during  the 
acquisition  cycle.  The  ASD  logistics  support  personnel 
are  uncertain  whether  the  MIS  currently  in  use  adequately 
provides  the  data  required  at  the  program  office/staff 
level.  They  have  written  a  Logistics  Management 

Information  Requirments  Identification  Plan  to  determine 
the  adequacy  of  the  current  MIS. (7)  The  plan  establishes 
an  eight  step  process  as  follows: 

1.  Identify  which  ASD  Program  Offices  should  be 


surveyed . 


2.  Select  one  represent i ti ve  logistics  element  -for 
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preliminary  survey. 

3.  Collect  and  analyze  data  -For  that  one  element. 

4.  Determine  the  -feasibility  o-f  surveying  the  other 
14  elements. 

5.  Collect  and  analyze  data  on  those  -feasible 
elements. 

6.  Investigate  existing  management  information 
systems  at  ASD. 

7.  Compare  reported  data  needs  to  available 

management  information  systems. 

8.  Develop/recommend  generic  MIS  format /contents. 


Steps  one  and  two 

have 

been  accomplished. 

The 

Logistics 

Element  that  has 

been 

selected 

for  prelimi 

nary 

survey  i s 

Technical  Orders 

(TO)  . 

Technical 

Orders  are 

the 

drawings. 

specifications. 

and  operating. 

maintenance. 

and 

repair  proceedures  for  a  weapon  system  being  procured. 


RESEARCH  QUESTION 


The  research 

question  investigated 

i  n 

thi  s 

study  i s 

what  information 

is  used  to 

manage 

and 

control  the 

acquisition  of  Technical  Orders? 

(Step 

three 

from 

above) 

RESEARCH  OBJECTIVE 

The  objective  of  this  research  is  to  answer  the 


research  question  by  accomplishing 


the 


f ol lowing 


subobjectives: 

1.  Determine  the  context  in  which  Technical  Orders 
acquisition  occurs. 

2.  Determine  what  -Functions  are  performed  in  the 
Technical  Orders  acquisition  process. 

3.  Determine  what  information  outputs  are  generated 
for  the  management  of  the  Technical  Orders  acquisition 
process. 

LITERATURE  REVIEW 

Most  methodologies  for  the  development  of  management 
information  systems  use  the  systems  approach  adopted  from 
general  systems  theory.  The  systems  approach  is  a  way  of 
looking  at  a  set  of  processes  or  functions  which  operate 
in  a  certain  environment  to  transform  a  set  of  inputs  into 
a  different  set  of  outputs.  In  the  past  20  years  a 
plethora  of  systems  development  methodologies  have  been 
written.  All  of  these  methodologies  break  the  development 
process  into  a  series  of  steps  or  phases.  Although  the 
number  and  titles  of  the  steps  may  differ  in  different 
methodologies,  the  general  philosophy  is  much  the  same. 
The  steps  in  three  representat i ve  methodologies  are  shown 
below: 

A.  Structured  Systems  Development  by  Ken  Orr  (17:198) 

1.  Plan  -  identify  and  scope  the  problem 

2.  Define  -  determine  user  needs,  functions,  and 

outputs 
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3.  Design  -  write  system  speci f i cati ons 

4.  Construct/Test  -  build  and  test  hardware  and 

sof  tware 

5.  Install  -  convert  -from  old  to  new  system 

6.  Operate  -  run  the  system 

7.  Use  -  use  the  products  of  the  system 

8.  Evaluate  -  examine  the  effectiveness  of  the  system. 


B.  Systems  Development  Methodology  by  Burch,  Strater,  and 
Grudnitski  (4:298) 

1.  Systems  Analysis  -  define  and  scope  the  problem; 

gather  and  analyze  user  needs 

2.  General  System  Design  -  develop  broad  design  and 

present  alternatives 

3.  Systems  Evaluation  and  Justification  —  analyze 

cost  effectiveness  and  employee  impact 

4.  Detail  System  Design  -  write  system  specifications 

5.  Systems  Implementation  -  train  users,  test  system, 

convert  to  new  system,  and  evaluate  new  system 


C.  Systems  Development  Methodology  by  Hice,  Turner  and 
Cashwel 1  (12:3,5) 

1.  Definition  Study  -  define  and  scope  the  problem, 

formulate  objectives,  conceive  potential 
solutions,  and  analyze  costs/benefits 

2.  Preliminary  Design  -  identify  system  functions, 

study  information  requirements,  and  define 
subsystems 

3.  Detail  Design  -  write  specifications 

4.  Program  and  Human  Job  Development  -  write  specific 

task  discriptions  and  software  programs 

5.  Testing  -  test  hardware  and  software  for  proper 

operation 

6.  Data  Conversion  and  System  Implementation  - 

convert  from  old  to  new  system 

7.  Operations  and  Maintenance  -  use  the  system,  train 

users,  and  keep  the  system  effective 


In  general ,  the  first  step  in  all  of  these 
methodologies  is  to  define  and  scope  the  problem, 
determine  the  user’s  needs,  and  determine  the  inputs  and 
processes  required  to  meet  those  needs.  The  second  step 
is  to  design  or  describe  in  general  terms  a  system  that 


will  meet  those  needs.  The  third  step  is  to  evaluate  and 


refine 

the  design 

to 

a  point 

where  procurement 

of 

the 

maj  or 

components 

can 

begin. 

The 

fourth 

step 

is 

to 

construct  and  test 

the 

system. 

The 

fifth 

step 

uses 

the 

test  results  to  further  refine  the  system’s  ability  to 
meet  the  user’s  needs.  The  sixth  step  is  to  implement  and 
use  the  system.  Since  no  organization  remains  static,  the 
seventh  step  is  to  continually  evaluate  the  effectiveness 
of  the  system.  If  new  needs  are  identified,  the  first 
step  is  begun  again  in  an  iterative  procedure. 

Despite  this  well-established  development  process. 


information  systems  developed 

to 

support 

the 

management 

process 

have  a  poor 

record 

of 

success. 

Dickson 

and 

Si mmons 

(8)  surveyed 

53 

firms 

experienced 

in 

MIS 

implementation  and  found  that  people  problems  were  the 
primary  cause  of  MIS  implementation  failures.  These 
people  problems  stem  from  user  di sati sf acti on  with  the 
system.  This  results  in  a  spectrum  of  behavior  from 
refusal  to  use  the  system  to  deliberate  sabotage  of  the 
system.  In  each  case,  the  people  problems  resulted  from 
the  developers’  failures  to  involve  upper  management  and 
the  system  users  in  the  development  process. 

Schewe  (21)  conducted  a  field  survey  of  79  MIS  users 
in  10  companies  to  determine  the  relationship  between  user 
attitudes  and  MIS  usage.  He  measured  user  attitudes, 
perceptions  of  the  hardware  and  software,  perceptions  of 
the  MIS  management,  and  system  use.  He  found  that  user 


attitudes  about  the  use-fulness  o-f  the  system  were  more 
in-fluenced  by  relations  with  the  MIS  staff  than  by  the 
physical  configuration  or  capabilities  of  the  computer 
hardware  used,  but  did  not  find  a  significant  relationship 
between  attitudes  and  system  use.  However,  Robey  (19) 
studied  the  sales  force  of  a  large  manufacturer  and  found 
significant  relationships  between  user  attitudes  and 
system  use.  Holland  (13)  interviewed  33  employees  in  3 
large  organizations  with  similar  results. 

Cheney  and  Dickson  (6)  performed  a  field  study  of  79 
users  in  8  companies  that  were  implementing  a  MIS  for  the 
first  time.  They  used  pre-installation  and 
post-installation  questionnaires  to  measure  user  decision 
style,  decision  environment,  job  satisfaction, 
satisfaction  with  the  information  provided  by  the  system, 
and  system  use.  User  satisfaction  was  found  to  be 
influenced  more  by  the  management  of  the  MIS  department 
than  by  system  technology,  and  they  concluded  that  proper 
management  of  the  MIS  was  more  important  than  the 
technical  sophistication  of  the  system. 

Roby  and  Farrow  (20)  looked  specifically  at  the 
user/MIS  staff  relationship.  They  conducted  a  field  study 
to  test  a  constructive  conflict  model  they  had  developed. 
The  model  links  user  participation  in  MIS  design  to 
influence,  conflict  and  conflict  resolution  with  the  MIS 
staff.  They  interviewed  62  users  in  8  companies  that  had 
recently  installed  an  MIS.  The  data  collected  supported 
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their  model.  User  participation  led  to  conflict,  and 
where  user  influence  was  allowed,  conflicts  were 
successfully  resolved. 

It  is  apparent  from  the  results  of  these  studies  that 
involvement  of  the  MIS  user  in  the  first  step  of  systems 
development  is  extremely  important.  It  is  the 
requirements  definition  step  that  provides  the  foundation 
upon  which  the  rest  of  the  system  is  built  -  in  fact,  it 
is  impossible  to  build  an  MIS  that  meets  the  user's  needs 
without  knowing  and  understanding  what  those  needs  are. 

A  recent  survey  of  60  managers  with  a  minimum  of  11 
years  MIS  experience  showed  that  both  user  participation 
in  MIS  development  and  user  satisfaction  with  the  system 
have  increased  considerably  in  the  past  five  years.  (22) 
This  increase  is  coincedent  with  the  recent  development 
and  use  of  a  number  of  requirements  definition  tools  and 
methodologies.  A  literature  review  by  Alpha  Omega  Sroup, 
Inc.  (2:24-43)  for  the  Office  of  Naval  Research  found  13 
techniques  that  have  been  used,  or  suggested  for  use,  as 
requirements  analysis  methodologies.  Two  of  these 
methodologies.  Structured  Analysis  and  Design  Technique 
(SADT)  by  Softec  Inc.  and  PSL/PSA  by  the  Department  of 
Industrial  and  Operations  Engineering  at  the  University  of 
Michigan,  have  gained  somewhat  wider  use  than  the  others, 
especial y  within  the  Department  of  Defense. 

The  Air  Force  uses  a  version  of  SADT  in  its 
Integrated  Computer — Aided  Manaf acturing  (ICAM)  System 
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Development  Methodology. 


ICAM  Defintion  ( IDEF)  is  the 


tt 


technique  used  in  the  definition/needs  analysis  phase  of 
the  methodology.  IDEF  produces  -function,  information,  and 
dynamic  models  o-f  the  system  under  study.  (16:3-14) 

The  David  W.  Taylor  Naval  Ship  Research  and 
Development  Center  also  uses  a  simplified  form  of  SADT  in 
its  Information  System  Design  Methodology.  Because  of  the 
size  of  the  system  the  Center  is  modeling,  it  also  uses 
PSL/PSA,  which  is  a  computer — based  technique.  The  data 
collected  using  the  functional  diagrams  are  expressed  in 
the  Problem  Statement  Language  (PSL)  and  stored  in  the 
Problem  Statement  Analyzer  (PSA)  data  base.  The  PSA  can 
produce  a  variety  of  reports  for  the  systems  analysts’  and 
designers’  needs. ( 14: 15-18)  However,  SADT,  IDEF,  and 
PSL/PSA  require  an  extensive  period  of  training  and  a  high 
level  of  user  sophistication. 

A  methodology  developed  by  Ken  Drr,  called 
Structured  Requirements  Defintion,  provides  a  similar 
approach  and  is  easier  to  learn  and  apply.  The  Orr 
methodology  emphasizes  definition  of  the  system  outputs  in 
two  sequential  phases.  In  the  first  phase,  the  logical 
definition  phase,  an  ideal  functional  definition  of  the 
outputs  is  accomplished  through  a  three  step  procedure 
that  correlates  with  the  subobjective  of  this  research. 
In  the  second  phase,  the  physical  definition  phase, 
constraints  and  characteristics  unique  to  the  specific 
user  are  incorporated.  Because  the  steps  in  the  logical 


definition  phase  correlate  with  the  subobjectives  of  this 
research,  structured  requirements  defnition  will  be  used 
for  this  research  application. 

Chapter  2  of  this  thesis  will  outline  and  describe 
the  procedure  and  tools  used  in  the  structured 
requirements  definition  methodology.  Chapter  3  will  then 
present  a  model  of  the  TO  acquisition  process  using  the 
tools  of  the  methodology.  Chapter  4  provides  a  summary, 
findings,  and  recommended  follow-on  research. 


CHAPTER  2 


METHODOLOGY 

STRUCTURED  REQUIREMENTS  DEFINITION 

Structured  Requrements  Definition  is  an 

output-oriented  methodology  that  defines  a  procedure  for 
using  a  related  set  of  tools.  Emphasis  is  placed  on 
defining  the  required  system  outputs.  The  tools  are  based 
on  set  and  systems  theory  and  have  been  modified  and 
improved  through  use  and  experience.  The  primary  tools 
are  the  entity  diagram,  Warnier/Orr  diagrams,  logical  data 
layouts,  and  a  data  dictionary. ( 17) 

TOOLS 

The  Entity  Diagram.  The  entity  diagram  was  developed 
to  help  the  analyst  get  the  project  started.  It  allows 
the  analyst  to  define  who  does  what  and  the  context  of  the 
system  being  analyzed.  For  each  entity  involved  in  the 
system,  an  ellipse  is  drawn  and  the  name  of  the  entity 
placed  inside.  Information  that  passes  between  entities 
is  defined  with  arrows  showing  the  direction  of  flow,  as 
shown  in  Figure  1.  The  entity  diagram  helps  the  system 
user  and  analyst  communicate  with  each  other  to  define  the 
scope  of  the  system.  But  even  more  can  be  deduced  from 
the  diagram.  For  example,  the  origin  and  termination  of 
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.ME  OF  ORGANIZATION 
ICE  OF  INTERVIEWEE 


ENTITY  DIAGRAM 


each  arrow  represents  events  such  as  sending  and  receiving 
a  report.  Thus,  events  important  to  the  system  can  be 
read  off  the  diagram. 

The  Warnier/Orr  Pi aqrams.  As  powerful  as  the  entity 
diagram  is,  it  is  only  the  starting  point  for  the 
requirements  process.  Warnier/Orr  diagrams,  logical  data 
layouts,  and  the  data  dictionary  are  used  to  further 
define  the  system  outputs. (17:89-94) 

Warnier/Orr  diagrams  come  from  the  formal  definition 
of  sets  used  in  mathematics  where  a  set  is  defined  through 
the  use  of  braces. 


X= 

{a,  b,  c,  d) 

In  the 

Warnier/Orr  diagram. 

the  equal 

sign  and 

right 

hand 

brace 

are  eliminated  and 

the  elements  of 

the 

set 

are 

listed 

vertically  instead 

of  horizontally. 

The 

elements 

have 

an  implied  sequence 

top  to 

bottom 

(a 

to 

d)  . 

Concurrency  is  indicated  by 

a  ’*  +  " 

which  is 

the 

logical 

"or”  symbol,  and  repetition  of  elements  is  indicated  by 
placing  the  number  of  repetitions  in  parenthesis  below  the 
name  (n),  (0,n)  etc.  This  convention  makes  it  easy  for 
Warnier/Orr  diagrams  to  represent  hierarchies  of 
information  sets  so  it  is  possible  to  describe  an  entire 
system  or  data  base  for  an  organization. ( 17: 65-69) 


2 


f  a 


Figure  2 

WARN I ER / ORR  DIAGRAM 


The  Assembly-Line  Diagram.  There  is  a  special  type 
of  Warnier/Orr  diagram  called  an  assembly-line  diagram  to 
aid  in  process  definition.  By  convention,  in  this 
diagram,  the  set  of  outputs  appears  on  the  left  of  the 
brace,  the  input  setts)  appear  on  the  right  at  the  top, 
and  the  process  set  appears  on  the  bottom  with  the 
concurrency  operation  "+"  between  them. 


{inputs 
+ 

process 


{inputs 
+ 

process 


Figure  3 

ASSEMBLY-LINE  DIAGRAM 


Here,  as  with  the  standard  Warnier/Orr 
no  limit  to  the  number  of  hierarchical 
decomposition.  The  assembly  line  di 


diagram,  there  is 
levels  for  output 
agram  is  used  to 
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delineate  the  -flow  of  information  in  a  system  and  identify 
the  needed  outputs  and  processes. ( 17: 70-89) 

The  Logi cal  Data  Layout.  Logical  data  layouts 
represent  a  model  of  the  output’s  physical  layout.  The 
logical  layouts  consist  of  three  elements: 

(1)  a  boundary 

(2)  "buckets”  for  elements 

(3)  the  element  names 

An  example  is  shown  below. ( 17: 95-97) 


LOGICAL  DATA  LAYOUT 


The  Data  Dictionaries.  The  data  dictionaries  provide 
a  reference  source  for  information  about  the  data  in  the 
system.  The  data  dictionary  provides  a  consistent  set  of 
names  to  use  when  referring  to  various  pieces  of 
information. (17:97-101) 


PROCEDURE 


The  procedure  for  using. these  tools  is  outlined  using 
a  Warnier/Orr  diagram  (Figure  5).  There  are  two 
sequential  phases  to  the  procedure:  the  logical 
definition  phase  and  the  physical  definition  phase.  In 
the  logical  definition  phase,  the  system  analyst  attempts 
to  define  the  ideal  functional  system,  thus  gaining  an 
understanding  of  what  must  be  done  to  support  the 
application.  Once  this  is  done,  the  physical  definition 
phase  is  used  to  deal  with  the  characteri sti cs  that  are 
unique  to  the  specific  user. (17:121-191) 

Logical  Definition  Phase.  The  first  step  in  the 
logical  definition  phase  is  to  define  the  application 
context.  Each  system  user  is  interviewed  and  an  entity 
diagram  created.  The  individual  entity  diagrams  are  then 
combined  to  make  one  overall  user  level  entity  diagram. 
This  diagram  will  usually  contain  too  much  information 
(all  the  interaction  within  the  system).  What  is  really 
needed  is  a  picture  of  only  the  critical  i nteracti ons. 
This  picture  is  achieved  by  defining  the  application  level 
entity  diagram.  A  boundary  is  drawn  around  all  the 
entities  internal  to  the  organization  under  study,  and 
these  entities  are  combined  into  one  el  ipse  representing 
the  organization.  This  strategy  suppresses  the  internal 
interactions  and  leaves  only  the  major  objectives  of  the 


j  ENTITY 
I  USER) 


DEFINITION  P] 


on  ideal  circumstance  -  that  every  thing  will  go  right. 


As  this  is  not  the  way  things  work  in  the  real  world, 
processes  must  be  added  to  handle  exceptions  and  errors. 
This  is  called  defining  the  control  and  feedback.  Once 
this  is  done  the  tasks  and  procedures  can  be  defined.  The 
Warnier/Orr  diagram  is  used  for  this  purpose.  The  diagram 
for  each  task  or  procedure  should  identify  the  outputs 
created,  the  actions  performed,  the  frequency  of  the 
actions,  and  the  information  required  to  perform  the 
actions. (17: 156-166) 

The  last  step  in  defining  the  application  functions 
is  to  define  the  decision  support  functions.  Decision 
support  functions  are  those  processes  management  uses  in 
planning  and  controlling  the  operations  of  the  system. 
The  task  here  is  to  get  management  to  identify  the  few  key 
variables  they  use  to  perform  these  tasks. ( 17: 167-173) 

The  third  and  last  step  in  the  logical  definition 
phase  is  to  define  the  application  results.  Before  the 
outputs  can  be  defined,  they  must  be  identified.  This  is 
done  by  creating  an  in-out  diagram  for  each  functional 
process  in  the  assembly-line  diagram.  The  in-out  diagrams 
give  a  simple,  exhaustive  list  of  the  outputs,  as  shown  in 
Figure  6.(17:173-174) 

Definition  of  the  outputs  involves  four  steps.  The 
output  form  is  defined  using  the  logical  data  layout.  A 
Warnier/Orr  diagram  is  created  to  define  the  output 
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Process 


(Input  1 
Input  2 
Input  3 
Output  1 
Output  2 
*  Output  3 
^  Output  4 


Figure  6 
IN-OUT  DIAGRAM 


structure.  The  output  content  is  displayed  using  a 
mock-up  or  sample.  At  the  same  time,  the  data  dictionary 
is  created  to  define  the  data  elements.  This  process 
provides  the  user  with  a  visual  example  of  the  outputs, 
which  makes  it  easier  for  him  to  get  an  idea  of  what  he 
will  be  getting  from  the  system  and  to  make  constructive 
changes  before  things  are  implemented.  The  only  remaining 
step  is  to  identify  the  frequency  of  occurence  for  each 
output  and  fit  the  outputs  into  a  total  picture  of  the 
system.  Again  a  Warnier/Orr  diagram  is  constructed  to 
display  the  total  system  picture.  To  this  point,  only  the 
ideal  functional  system  has  been  addressed,  so  it  is  then 
necessary  to  address  the  technical  aspects.  These  have 
been  left  to  the  physical  requirments  definition 
phase. (17:173-133) 

Physi cal  Def ini tion  Phase.  In  this  phase  critical 
constraints  such  a  volumes,  response  times,  security  of 


data. 


sof tware. 


computer 


hardware 


rel i abi 1 i ty. 


organizational  considerations,  and  costs  and  schedules  are 


identified.  Once  the  constraints  have  been  identified, 
alternative  solutions  to  providing  the  functions 
identified  in  the  logical  definition  phase  can  be 
identified,  analyzed  and  a  recommended  course  of  action 
selected.  Finally  a  requirments  definition  document  is 
written  to  describe  exactly  what  was  discovered  in  the 
requirments  definition  process.  The  document  should 
summarize  and  present  the  material  that  was  developed 
during  the  logical  and  physical  definition 
processes. (17: 1B3-191) 

APPLICATION 

The  logical  definition  phase  of  the  structured 
requirements  definition  procedure  provides  a  method  to 
achieve  the  three  subobjectives  of  this  research.  The 
three  major  steps  in  the  procedure  correlate  with  the 
three  subojecti ves:  To  determine  the  context,  functions, 
and  outputs  of  the  technical  order  acquisition  process. 

The  entity  diagram  was  used  to  conduct  structured 
interviews  with  members  of  seven  Technical  Order 
Management  Agencies  (TOMAs)  within  ASD  and  the  ASD  staff 
TO  specialist.  This  information,  and  information  gained 
from  a  review  of  AF  manuals  and  regulations  on  TO 
acquisition,  and  the  logical  definition  phase  procedure 
were  used  to  create  the  TO  acquisition  process  model 
presented  in  Chapter  3. 
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CHAPTER  3 


TECHNICAL  ORDER  ACQUISITION  PROCESS  MODEL 

• 

INTRODUCTION 

The  results  of  this  research  are  presented  in  three 
sections  which  correspond  to  the  research  subobjectives 
and  the  three  steps  o-f  the  logical  de-finition  phase  o-f  the 
methodology  outlined  in  Chapter  2.  The  tools  defined  in 
Chapter  2  are  used  in  presenting  the  model.  The  context 
de-finition  section  presents  the  application  entity  diagram 
and  application  objectives.  The  -functional  de-finition 
section  presents  the  assembly-line  diagram  and  describes 
the  application  and  decision  support  functions.  The 
output  identification  section  identifies  and  describes  the 
outputs  used  to  manage  the  process. 


CONTEXT  DEFINITION 

The  application  entity  diagram  in  Figure  7  identifies 
the  types  of  organi zati ons  and  interfaces  involved  in  the 
Technical  Order  (TO)  acquisition  process.  Figure  7  is  a 
summary  of  the  individual  entity  diagrams  contained  in 
Appendix  A.  The  diagram  indicates  that  the  Technical 
Order  Management  Agency  (TOMA)  is  the  manager  of  a  team 
consisting  of  the  user  of  the  system  being  procured,  the 
AFLC  Air  Logistics  Centers  (ALCs)  responsible  for  support 
of  the  system,  the  agency  responsible  for  operational  test 
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Figure 


TCMA  TEST  AGENCY  INTERFACE 


TOMA  AFLC/ALC  INTERFACE 


TCMA  USER 


ACTOR  TOMA 


and  evaluation  of  the  system  and  the  contractor  producing 
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the  system.  This  team  is  responsible  -for  the  type, 
quantity,  and  quality  o-f  the  technical  orders  the 
contractor  delivers.  The  TOMA  also  obtains  guidance  on  TO 
acquisition  policy  -from  the  ASD  Deputy  -for  Acquisition 
Support  (ASD/AWL)  and  guidance  on  TO  safety  content  from 
various  safety  organizations.  The  TOMA  itself  is  a  team 
of  personnel  from  different  offices  within  the  system 
program  office  responsible  for  acquisition  of  the  system. 

The  interfaces  between  the  organizations  in  the 
application  entity  diagram  provide  an  initial  set  of 
objectives  for  the  TO  acquisition  process.  These 
objectives  are  used  in  developing  the  assembly-line 
diagram  which  facilitates  functional  definition.  A  number 


of  the  interfaces. 

such 

as 

the 

data 

calls. 

occur 

simultaniously  and  are 

consi dered 

a 

single 

action. 

A1  so. 

those  interfaces  where 

the 

TOMA, 

user 

,  and 

ALC  work 

as  a 

team  with  the  contractor,  such  as  with  In— Process  Review 
(IPR)  comments,  are  treated  as  a  single  action. 
Therefore,  the  list  of  objectives  below  i~  shorter  than 
the  total  number  of  interfaces  in  Figure  7. 

Objectives 

1.  Send  data  call  (to  users,  ALC,  and  test  agency) 

2.  Receive  data  requirements  (from  users,  ALC,  and  test 
agency) 


3.  Send  Request  For  Proposal  (RFP)  (to  contractor) 


4.  Receive  proposal  (from  contractor) 

5.  Award  contract  (to  contractor) 

6.  Receive  draft  Specification  Interpretat i on  Document 
(SID)  and  TO  recommendations  (from  contractor) 

7.  Send  policy  and  guidance  (to  contractor) 

8-  Send  In-Process  Review  (IPR)  comments  (to  contractor) 

9.  Send  validation  comments  (to  contractor) 

10-  Receive  Preliminary  Technical  Orders  (PTOs) (from 
contractor ) 

11.  Send  verification  comments  (AFTO  Form  27)  (to 
contractor ) 

12.  Receive  TO  negatives  (from  contractor) 

13.  Send  TO  negatives  (to  ALC  and  Printer) 

14.  Receive  Contractor  Furnished  Equipment  Notice  (CFEN) 
(from  contractor) 

15.  Send  CFEN  approval  (to  contractor) 

16.  Receive  Engineering  Change  Proposals  (ECPs)  (from 
contractor ) 

17.  Send  ECP  approval  (to  contractor) 

18.  Receive  TO  changes  (from  user  and  ALC) 

19.  Send  approved  TO  changes  (to  contractor) 

20.  Receive  TO  change  negatives  (from  contractor) 

21.  Send  TO  change  negatives  (to  ALC  and  printer) 

FUNCTIONAL  DEFINITION 

The  assembly  line  diagram  shown  in  Figure  8  defines 
the  main-line  functional  flow  and  identifies  the  principal 


outputs  and  -functional  processes  that  constitute  the  TO 
acquisition  process.  The  decision  support  functions  used 
to  plan  and  control  this  process  were  identified 
separately,  but  they  will  also  be  discussed  where  they 
occur  in  the  process.  Each  output  and  functional  process 
is  discussed,  starting  with  the  data  call  and  requirements 
identification  process,  and  concluding  with  the  printing 
of  the  TO. 

The  data  call  is  a  request  to  all  affected  agencies 
to  identify  the  type  and  quantity  of  TO  and  decision 
support  documentation  they  require.  Receipt  of  the  data 
requirements  starts  the  requirements  def inition— RFP 
preparation  process.  During  this  process  the  TOMA 
organizes  and  consolidates  the  requirements  of  the 
interested  agencies  and  obtains  clarif i cation  from  them  on 
any  unclear  areas  and  justification  for  requirements  that 
seem  unwarranted.  The  TOMA  prepares  two  documents  for  the 
RFP,  a  statement  of  work  which  defines  the  work  effort 
expected  of  the  contractor  and  the  contract  data 
requirements  list  (CDRL)  which  identifies  specifically 
what  data  are  to  be  prepared  and  delivered.  The  first 
decision  support  function,  TO  Publication  Planning,  takes 
place  during  this  process  also.  A  TO  Publication  Plan 
(TOPP)  outlines  in  detail  how  the  entire  TO  acquisition 
process  will  be  conducted.  A  draft  TOPP  is  usually 
included  in  the  RFP  to  serve  as  a  guide  for  the  contractor 
to  follow  in  developing  a  detailed  TOPP. 
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MAIN-LINE  FUNCTIONAL  FLOW 


Because  the  TO  requirements  are  defined  early  in  the 
design  of  the  system  being  procured,  not _  all  TO 
requirements  can  be  identified  during  the  requirements 
definition  process.  The  Contractor  Furnished  Equipment 
Notice  (CFEN)  is  a  standard  format  the  contractor  uses 
throughout  the  design  of  the  system  to  recommend 
additional  TO  requirements  as  they  are  identified.  An 
approved  CFEN  performs  the  same  function  as  the  RFP.  They 
both  prompt  a  contractor  to  submit  a  proposal  that  defines 
how  he  will  meet  the  TO  requirments  and  the  cost  of  doing 
so.  The  proposal  is  reviewed  by  the  TDMA,  user,  ALC  team, 
and  a  contract  or  contract  modification  is  negotiated  and 
awarded. 

The  award  of  the  contract  starts  the  specification 
i nterpretat i on  (SID)  process.  During  the  process  the 
contractor  prepares  a  draft  SID,  which  identifies  the 
modifications  and  waivers  to  the  contract  speci f i cati ons 
necessary  to  tailor  the  TOs  to  the  system  being  procured 
and  the  contractor  also  writes  the  detailed  TOPP.  Both 
are  reviewed  by  the  TDMA,  user,  ALC  team,  and  a  guidance 
conference  is  held  in  which  the  contractor  receives 
comments  and  guidance  on  the  SID  and  TOPP.  When 
understanding  of  the  requirements  is  reached  by  all 
parties,  the  SID  and  TOPP  are  approved  and  a  number  is 
assigned  for  each  deliverable  TO.  With  this  accomplished 
the  contractor  begins  writing  the  TOs. 


During  the  writing  process  the  second  decision 
support  -function,  status  and  schedule  monitoring,  begins. 
The  contractor  submits  monthly  status  and  schedule 
reports,  and  In-process  reviews  (IPR’s)  are  held  to 
evaluate  the  contractors  progress  and  understanding  o-f  the 
TO  requirements.  Guidance  on  technical  content  and  safety 
requirements  is  provided,  and  meeting  minutes  are  kept  to 
record  action  items  and  policy  decisions  agreed  to  during 
the  reviews. 

Changes  in  the  design  or  configuration  of  the  system 
will  usually  have  some  effect  on  the  TOs.  Therefor,  the 
TOMA  participates  in  the  review  and  approval  of  ECPs  to 
ensure  that  the  appropriate  changes  are  incorporated  in 
the  TOs.  Once  the  ECPs  and  IPR  guidance  are  incorporated 
into  the  draft  TOs,  the  contractor  validates  the  draft  by 
actual  performance  of  the  operating  and  maintenance 
procedures  on  the  system.  Representatives  of  all  the 
interested  organizations  attend  validation.  Because  this 
is  the  first  time  the  written  procedures  are  performed, 
there  are  usually  a  large  number  of  deficiencies 
identified  and  provided  to  the  contractor  as  validation 
comments.  The  contractor  incorporates  these  comments  into 
the  draft  TO,  converting  it  to  a  preliminary  TO  (PTO) 
which  is  delivered  to  the  TOMA  for  verification. 

The  verification  process  is  similar  to  validation 
except  user  personnel  perform  the  procedures.  A  third 
decision  support  function,  verification  planning,  supports 
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this  process.  The  TOMA  or  verification  agent,  usually  the 
operational  test  and  evaluation  agency,  does  the  planning. 
Deficiencies  found  in  the  PTO  during  the  verification 
process  are  provided  to  the  TOMA  and  contractor  on  AFTO 
Form  27. 

The  contractor  uses  the  AFTO  Form  27  to  update  the 
PTO  converting  it  to  a  formal  TO.  Prior  to  delivery  of 
negatives  from  which  the  TO  is  printed  a  pre-publication 
review  is  held  to  verify  that  all  of  the  verification 
deficiencies  have  been  corrected.  TO  printing  is 
accomplished  by  the  TOMA  through  Government  Printing 
Office  established  contracts.  Distribution  of  the  TO  is 
controlled  by  the  Oklahoma  City  ALC. 

The  TOMA  and  contractor  may  become  involved  with  the 
Technical  Order  Improvement  Reporting  System  (AFTO-22 
System)  if  the  TO  is  fielded  and  put  to  use  before  the 
transfer  of  management  responsibility  to  the  responsible 
ALC. 

OUTPUT  IDENTIFICATION 

The  TO  acquisition  process,  as  shown  above,  is 
managed  through  three  decision  support  functions,  TO 
Publication  Planning,  verification  planning,  and  status 
and  schedule  maintenance.  Each  of  these  functions 
produces  one  or  more  outputs.  TO  publication  planning 
produces  the  TOPP.  Verification  planning  produces  the 
verification  plan.  Status  and  schedule  maintenance 
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produces  a  number  of  status  and  schedule  reports  and 
meeting  minutes  reports. 

The  TOPP  is  the  primary  planning  document  for  TO 
acquisition.  It  contains  the  requirements  for  style, 
type,  quantity,  and  quality  o-f  the  TOs  being  procured,  as 
well  as  a  delineation  of  the  responsibilities  of  the 
agencies  involved,  and  a  schedule  tying  the  TO  acquisition 
milestones  to  the  system  design  and  production  milestones. 
A  detailed  plan  for  the  contractors  validation  effort  is 
also  included.  The  TOPP  contains  detailed  plans  for  every 
function  in  the  acquisition  process  except  verif ication. 

The  verification  plan  defines  the  objectives, 
requirements,  and  responibilities  of  the  agencies 
involved.  Scheduling  of  the  personnel  and  equipment  is 


extremely  difficult 

because  i t 

is 

impacted 

by 

the 

Operational  test  and 

evaluation 

(DTSeE) 

schedule 

and 

the 

availability  of  PTOs. 

Theref ore, 

the 

(DTSeE)  schedule 

i  s 

usually  followed.  The  verification  plan  does  identify 
whether  full  verification  (one-step)  or  partial 
verification  (two-step)  will  be  conducted  on  each  TO.  In 
the  latter  case  the  PTO  is  published  as  partially  verified 
and  does  not  become  a  formal  TO  until  its  entire  contents 
are  verified. 

The  status  and  schedule  report  is  the  primary 
management  control  document.  It  is  usually  submitted  by 
the  contractor  on  a  monthly  basis  after  the  initial 
submittal  and  contains  the  status  and  schedule  of  the 
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events  outlined  in  the  TOPP.  Each  TO  being  procured  is 
treated  separately  in  the  report.  In  TO  acquisitions 
where  a  large  number  of  TOs  are  initiated  throi^gh  the  CFEN 
process,  the  TOMA  maintains  a  separate  status  and  schedule 
report  to  track  the  actions  and  costs  required  in 
processing  the  CFENs.  Meeting  minutes  are  also  used  to 
track  the  progress  and  completion  of  action  items 
identified  during  in-process,  pre-publ i cation,  and 
post-publication  reviews  and  guidance  conferences. 

SUMMARY 

This  chapter  presented  a  model  of  the  TO  acquisition 
process.  Basically,  five  agencies  work  together  as  a  team 
to  perform  the  processes  outlined  in  the  main-line 
functional  flow  shown  in  Figure  8.  The  TOMA  uses  three 
decision  support  functions  to  manage  the  team’s  effort. 
First,  TO  publication  planning  produces  the  TOPP  which 
identifies  in  detail  who  does  what  and  when.  Second, 
status  and  schedule  reporting  is  done  to  insure  the  plan 
is  followed,  and  finally,  verification  planning  helps 
bring  together  the  men  and  equipment  necessary  to 
accomplish  a  smooth  verification  effort.  The  outputs  of 
these  three  functions  were  identified  and  discussed. 
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CHAPTER  4 


SUMMARY /FINDINGS/RE COMMENDAT I ON 

SUMMARY 

This  thesis  answers  the  question  asked  by  the  ASD 
Logistics  Support  Personnel  of  what  information  is 
currently  used  to  manage  and  control  the  acquisition  of 
Technical  Orders.  Answering  the  question  was  the  third 
step  of  a  larger  effort  to  determine  the  adequacy  of  the 
existing  logistics  MISs  at  ASD.  A  review  of  information 
requirements  definition  methodologies  was  conducted,  and 
the  logical  definition  phase  of  Structured  Requirements 
Defintion  by  Ken  Orr  was  selected  as  the  most  appropriate 
methodology  to  answer  the  research  question.  This 
methodology  emphasizes  defining  required  system  outputs, 
and  consists  of  a  three  step  procedure  for  using  a  set  of 
related  tools.  These  three  steps,  which  correlate  with 
the  thesis  subobjectives,  are  context  definition, 
functional  defintion,  and  output  definition. 

In  the  context  definition  step  the  entity  diagram  was 
used  to  interview  seven  TOMA’s  within  ASD  and  the  ASD 
staff  TO  specialist.  The  information  gathered  from  the 
interviews  and  a  review  of  AF  Regulations  and  manuals  on 
TO  acquistion  revealed  there  are  five  primary  agencies 


involved  in  the  TO  acquisition  process.  These  five 
agencies  are  the  TOMA,  user,  AFLC/ALCs,  Test  agency,  and 
contractor.  The  information  gathered  also  indicates  that 
there  are  some  21  major  transactions,  called  objectives, 
that  occur  between  these  agencies. 

In  the  functional  definition  step  the  21  objectives 
were  used  to  create  an  assembly-line  diagram  that  allowed 
definition  of  the  main  functional  processes  and  their 
associated  inputs  and  outputs.  Three  decision  support 
functions  or  management  functions,  used  to  plan  and 
control  the  TO  acquisition  process,  were  also  identified. 
These  functions  are  Technical  Order  Publication  Planning, 
verification  planning,  and  status  and  schedule  monitoring. 

In  the  output  definition  step  the  outputs  of  the 
three  decision  support  functions,  the  TOPP,  verification 
plan,  status  and  schedule  reports  and  meeting  minutes  were 
identified  and  described. 

FINDINGS 

The  Structured  Requirements  Definition  methodology 
was  easy  to  learn  and  apply.  The  entity  diagram  is  an 
effective  tool  for  conducting  personal  interviews.  It 
helps  keep  the  interviewee  an  the  subject  at  hand  and 
provides  an  easy  way  of  recording  the  information  provided 
during  the  interview.  However,  the  interview  topic  must 
be  kept  relatively  simple  in  scope  or  the  entity  diagram 
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will  become  too  complex  to  maintain. 


The  assembly-line 


diagram  was  also  a  convenient  and  easy  tool  to  use  to 
identify  a  systems  inputs,  outputs,  and  processes. 

As  a  result  of  the  interviews  and  TO  document ion 
review,  three  findings  emerged  which  were  not  in  the 
mainstream  of  this  research,  but  are  of  such  significance 
that  they  should  be  reported. 

First,  there  are  no  specific  job  descriptions  or 
qualifications  for  TOMA  personnel,  and  the  TOMA  is 
susceptible  to  rapid  turnover  of  personnel.  This  was 
also  a  finding  in  a  study  performed  for  the  Air  Force 
Human  Resources  Laboratory  (11:9).  Second,  there  is  no 
single  comprehensive  source  of  or  responsibi 1 ty  center  for 
information  describing  the  TO  acquisition  process.  This 


makes 

it 

difficult  for  inexperienced 

TOMA 

personnel 

to 

learn 

the 

process.  Third,  very 

little. 

if 

any. 

of 

the 

management 

information  collected 

and  used 

by 

the 

TOMA 

is 

reviewed  by  higher  levels  of  management.  Together,  these 
findings  indicate  a  lack  of  attention  to  TO  acquisition  by 
senior  Air  Force  management. 

RECOMMENDATION 

Further  research  should  be  conducted  to  determine  the 
information  required  to  manage  the  other  14  system 
acquisition  logistics  elements.  The  findings  of  this  and 
future  research  can  then  be  compared  to  the  information 
available  in  ASD’s  current  management  information  systems 
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